CentOS 7 (OpenVZ): tīkls nepalaižas pēc pārstartēšanas — [fix]
Situācija, kad pēc pārstartēšanas CentOS 7 konteinerī (OpenVZ) pēkšņi “pazūd” tīkls, ir nepatīkama, bet salīdzinoši tipiska: serviss nepaceļ interfeisu, maršruti neuzliekas, DNS nestrādā, un jūs vairs nevarat pieslēgties no ārpuses. Bieži vien tas notiek pēc atjauninājumiem, konfigurācijas izmaiņām, vai arī pēc tam, kad hosta pusē ir mainīts virtuālā interfeisa tips/parametri. Šajā pamācībā ir fokusēts, praktisks ceļš, kā atjaunot tīklu, saprast iemeslu un nodrošināt, lai problēma neatkārtojas.
Ja jums ir kritiska sistēma, kurai svarīgs stabils tīkls un piekļuve pēc restarta, apsveriet arī infrastruktūras izvēli: mūsdienīgākam izolācijas modelim un elastīgākiem tīkla iestatījumiem parasti izvēlas VPS. Ja jums vajag garantētu resursu līmeni un pilnu kontroli pār aparatūru, ir serveru īre. Savukārt, vienkāršām vietnēm ar standarta prasībām bieži pietiek ar hostingu.
Galvenais princips: vispirms atgūstam savienojumu (kaut vai caur konsoli/serial/hosta paneli), tad diagnosticējam, kas īsti netiek palaists: interfeiss, tīkla serviss, konfigurācijas faili, vai DNS. OpenVZ konteineros ir nianses: dažas tīkla lietas kontrolē hosts, un konteinerī nevar pilnībā uzvesties kā “parastā” VM. Tāpēc arī “fix” bieži ietver gan OS servisu, gan konkrētus ifcfg failus.
1) Ātra diagnostika: vai interfeiss eksistē un kāds ir statuss
Pēc restarta vispirms pieslēdzieties konteinerim ar pieejamo metodi (provider panelis, VNC/console, vai hosta konteinera konsoles piekļuve). Pēc tam pārbaudiet, vai redzat tīkla interfeisu un IP adresi. CentOS 7 gadījumā interfeiss var būt eth0, venet0 vai veth0 atkarībā no OpenVZ konfigurācijas. Komandas, kas ātri pasaka situāciju: “ip a”, “ip link”, “ip r”.
Ja interfeiss nav “UP”, bet tas ir redzams, iespējams, tīkla serviss to nepaceļ vai konfigurācijā trūkst ONBOOT=yes. Ja IP adrese ir pazudusi, iespējams, ifcfg fails ir bojāts vai ir konflikts ar NetworkManager. OpenVZ konteineros bieži izmanto klasisko network servisu, bet dažās instalācijās NetworkManager var radīt “neprognozējamu” uzvedību, īpaši servera vidē.
Vēl viena ātra pārbaude: “systemctl status network” un “journalctl -u network -b”. Ja redzat kļūdas par interfeisa nosaukumu vai “device not found”, tas parasti nozīmē, ka ifcfg failā norādītais DEVICE neatbilst reālajam interfeisam (piem., ifcfg-eth0, bet reāli ir venet0). Šis ir viens no biežākajiem iemesliem, kāpēc tīkls nepalaidās pēc restarta.
2) Klasiskais labojums: ifcfg failu sakārtošana un network servisa restarts
CentOS 7 klasiskā tīkla konfigurācija atrodas /etc/sysconfig/network-scripts/. Meklējiet ifcfg failu, kas atbilst jūsu interfeisam. Piemēram, ja interfeiss ir eth0, failam bieži ir nosaukums ifcfg-eth0. Pārbaudiet šādus laukus: DEVICE, BOOTPROTO, ONBOOT, IPADDR, NETMASK (vai PREFIX), GATEWAY, DNS1/DNS2. Minimāli ONBOOT jābūt “yes”, lai interfeiss startējas pēc restarta.
Ja jums ir statiska IP, pārliecinieties, ka IPADDR un GATEWAY ir korekti. OpenVZ konteineros gateway dažreiz ir hosta virtuālais maršrutētājs (piem., 10.0.0.1 vai līdzīgs), un to parasti nosaka providers. Ja jūs uzlikāt “nepareizu” gateway, tīkls var izskatīties “paceļas”, bet ārā nekas nestrādā (nav maršruta uz internetu). Tāpēc pārbaudiet “ip r”, vai ir default route.
# piemērs: /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet DEVICE=eth0 ONBOOT=yes BOOTPROTO=static IPADDR=203.0.113.10 PREFIX=24 GATEWAY=203.0.113.1 DNS1=1.1.1.1 DNS2=8.8.8.8
Pēc faila labojumiem palaidiet “systemctl restart network” un pārbaudiet “ip a” un “ip r”. Ja tas nestrādā, mēģiniet “ifdown eth0; ifup eth0” (ja rīki pieejami). Atcerieties, ka OpenVZ vidē interfeiss var nebūt “Ethernet” klasiskā nozīmē, bet šāds ifcfg formāts joprojām bieži strādā.
Ja izmantojat DHCP (retāk serveriem), pārliecinieties, ka BOOTPROTO=dhcp un ka hosta pusē DHCP tiešām tiek nodrošināts. Ja DHCP netiek atbalstīts, tīkls nepalaidīsies, jo tas gaidīs adresi, ko nekad nesaņems. Šī ir vēl viena tipiska situācija pēc “pārcelšanas” starp hostiem vai pēc container template maiņas.
3) NetworkManager konflikts un rekomendētais servera režīms
CentOS 7 bieži nāk ar NetworkManager. Serveru vidē, īpaši OpenVZ konteineros, vienkāršāk un stabilāk ir izmantot klasisko network servisu un NetworkManager atslēgt (vai vismaz neļaut tam pārvaldīt servera interfeisu). Ja pēc restarta NetworkManager “pārņem” interfeisu, tas var ignorēt jūsu ifcfg parametrus vai uzlikt citu profilu.
Ja redzat, ka network serviss saka “OK”, bet IP nav, pārbaudiet “systemctl status NetworkManager”. Ja tas aktīvs un manipulē ar interfeisu, apsveriet to atslēgt: “systemctl disable --now NetworkManager” (tikai tad, ja zināt, ka jums tas nav vajadzīgs). Pēc tam restartējiet network servisu. Šo soli vienmēr veiciet uzmanīgi un tikai ar konsoles piekļuvi, lai nepazaudētu pēdējo piekļuves kanālu.
4) DNS problēmas, kas izskatās kā “nav tīkla”
Dažreiz IP un maršruts ir, bet “nekas nestrādā”, jo nedarbojas DNS. Pārbaudiet: “ping 8.8.8.8” un “ping google.com”. Ja ping uz IP strādā, bet uz domēnu nē, problēma ir /etc/resolv.conf vai DNS iestatījumos. OpenVZ vidē /etc/resolv.conf var tikt pārrakstīts. Iestatiet DNS1/DNS2 ifcfg failā un pārstartējiet tīklu, vai arī uzlieciet pareizos nameserver ierakstus resolv.conf (un nodrošiniet, lai tie netiek pārrakstīti pēc restarta).
Ja izmantojat iekšējo DNS (piem., uzņēmuma VPN), pārliecinieties, ka ir pareizi maršruti uz šo DNS un ka ugunsmūris (iptables/firewalld) nefiltrē DNS portus. CentOS 7 ugunsmūris var būt ieslēgts pat konteinerī, un dažreiz pēc update tas sāk darboties citādi. Pārbaudiet “systemctl status firewalld” un noteikumus.
5) OpenVZ specifika: venet/veth un hosta konfigurācija
OpenVZ var izmantot venet (routēts interfeiss bez L2) vai veth (virtuāls Ethernet). Ja hosta pusē mainīts režīms, konteinerī var mainīties interfeisa nosaukums un uzvedība. Piemēram, venet režīmā var nebūt klasiskas ARP uzvedības, un dažas komandas var rādīt citādus rezultātus. Ja pēc restarta redzat, ka interfeiss vairs nav tas pats, salīdziniet “ip link” ar ifcfg DEVICE. Tieši šī neatbilstība visbiežāk salauž automātisko tīkla startu.
Ja konteinerī nav iespējas iestatīt IP, jo hosts “push” konfigurāciju, sazinieties ar pakalpojumu sniedzēju vai pārbaudiet hosta paneli: IP, maska, gateway, DNS var tikt definēti ārpus konteinera. Tad “fix” konteinerī var būt vienkārši nepareiza lokālā konfigurācija, kas konfliktē ar hosta uzspiestajiem parametriem. Šādā gadījumā vislabāk ir atgriezties pie minimālas, saderīgas konfigurācijas.
Pārbaudes soļi pēc labojuma un profilakse
Pēc labojuma veiciet sistemātisku pārbaudi: (1) “ip a” — vai ir IP; (2) “ip r” — vai ir default route; (3) “ping gateway” — vai sasniedzams; (4) “ping 8.8.8.8” — vai ir internets; (5) “ping domēns” — vai strādā DNS; (6) pārstartējiet konteineri vēlreiz, lai pārliecinātos, ka problēma neatkārtojas. Ja pēc otrā restarta viss paliek labi, konfigurācija ir noturīga.
Profilakse: uzturiet ifcfg failus vienkāršus, izvairieties no nevajadzīgām “modernām” tīkla abstrakcijām konteinerī, un pirms atjauninājumiem saglabājiet tīkla konfigurācijas kopiju. Ja jums regulāri vajag stabilu, prognozējamu tīklu pēc restarta un iespēju elastīgi mainīt tīkla iestatījumus pašam, izvērtējiet pāreju uz VPS/VM tipa risinājumu, kur OS tīkla steks ir pilnībā jūsu kontrolē.